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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates to a method and 
system for controlling processing load in a packet data 
network, such as an Internet Protocol (IP) Multimedia 
Subsystem (IMS) provided on top of a packet data net- 
work to offer voice and multimedia services e.g. for third 
generation mobile devices. 

BACKGROUND OF THE INVENTION 

[0002] It is assumed that in the future almost all fixed 
and mobile communications networks will be based on 
Internet technology. Especially, services combining sev- 
eral communication types and modes will lead the way 
in future networks. Voice itself will be just one, although 
important, piece in the whole communication architec- 
ture. 

[0003] The Session Initiation Protocol (SIP) as defined 
in the Internet Engineering Task Force (IETF) specifica- 
tion RFC 3261 , provides an emerging standard for setting 
up multimedia sessions on the Internet. Its basic capa- 
bilities are setup modification and tear down of any com- 
munication session, so it is a signaling protocol. SIP also 
provides personal mobility, meaning that a consumer is 
reachable via a single address regardless of its current 
point of attachment to the network. 
[0004] In order to support multimedia services, seam- 
less mobility and efficient multiparty conferencing, the IP 
layer needs to be enhanced. Mobile IP allows terminals 
to move freely between different mobile networks. 
[0005] SIP is used to establish, modify and terminate 
sessions. It provides personal mobility by allowing a user 
to dynamically register to the network with his communi- 
cation address, i.e. SIP URI (Uniform Resource Indica- 
tor). A session is usually a number of Real-time Transport 
Protocol (RTP) streams to be exchanged. Normally, a 
session is a combination of speech, audio and video 
streams, but it may also contain shared applications. A 
basic SIP network is composed of four types of elements 
i.e. User Agents (UA), Proxy Servers, Redirect Servers 
and Registrar Servers. User Agents typically reside in 
endpoints such as IP phones, personal computers or mo- 
bile devices. They initiate requests and provide respons- 
es. Usually, UAs also have an interface to media handling 
and to the actual application software providing the user 
interface. Proxy servers are intermediaries, which re- 
ceive and forward requests providing them with, e.g., 
routing or other services. Redirect servers simply re- 
spond to a request by asking its originator to redirect it 
to a new address. Registrar servers keep track on the 
actual points of contact of the consumers by accepting 
registrations from the UAs. Registrar servers and the SIP 
registration procedure in general provide user mobility 
as the consumer is able to be reachable from any location 
via a single address. In this sense, they resemble Home 



Location Register (HLR) functionality in the Global Sys- 
tem for Mobile communications (GSM) networks. Each 
consumer is part of a domain and each domain runs at 
least one registrar server, which knows the location of its 

5 consumers if the are registered. 

[0006] SIP uses an address format common to Internet 
Mail, i.e. "user@domain". The domain part is used to find 
the correct domain for the consumer and the user part is 
used to distinguish between individual consumers within 

10 a domain. SIP includes request and response messages 
comprising header fields, e.g. for defining where the re- 
quest is to be sent next, the recipient address, the sender 
address etc. Furthermore, a SIP message may contain 
a payload portion for transmitting subscriber or service 

is specific information. 

[0007] It is noted that RTP streams do not follow the 
same path as the SIP message did, but flow directly be- 
tween the concerned devices. It is thus possible to send 
the subsequent SIP requests directly between the UAs. 

20 In IMS, subsequent SIP messages follow the path re- 
corded into the Record-Route header of the initial re- 
quest, while interrogating network nodes may drop them- 
selves out and other network elements stay on path. On 
the other hand, proxy servers in the middle may ask to 

25 remain on the signaling path for the duration of the call. 
This might be useful if the proxy offers some services to 
the call. 

[0008] Currently, the Third Generation Partnership 
Project (3GPP) is specifying IMS e.g. in its specification 

30 TS 23.228 as an access independent subsystem which 
can be used in connection with different networks. IMS 
uses SIP for session initiation. Basically IMS is just an 
instance of a SIP network. It has a number of proxies and 
a registrar. The UA is situated in the terminal device or 

35 user equipment (UE). When two devices establish a ses- 
sion they talk to each other via Call State Control Function 
or Call Session Control Function (CSCF) elements, while 
RTP media flows do not go via CSCFs but go directly 
between the devices. An Application Server (AS) is a SIP 

40 element dealing with services, such as advanced call 
control, presence or instant messaging. The AS may ter- 
minate sessions/transactions. The AS may also start ses- 
sions/transactions e.g. on behalf of a user or a service. 
[0009] However, there may be situations where the AS 

45 does not know whether it should start originating or ter- 
minating services when it receives an incoming request 
message, e.g. an SIP INVITE message, or a serving 
CSCF (S-CSCF) does not know whether the incoming 
request message starts an originating or terminating ses- 

50 sion/transaction. Moreover, other information may be 
needed for load balancing within the network. Further- 
more, for load sharing purposes in a connection process- 
ing server (CPS), especially in the S-CSCF and an inter- 
rogating CSCF (l-CSCF), it is important to provide a fast 

55 and easy algorithm to discover whether a received SIP 
request is the first in a SIP session or to which SIP session 
a received request or response belongs to. Currently, 
SIP does not provide such an efficient means. In order 
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to identify a SIP dialog, i.e. call leg, identified by a com- 
bination of call identification, source and destination, a 
network element or UE has to compare the respective 
headerf ields of each SIP message and then to determine 
whether the call leg already exists. This implies heavy 
string comparisons and data base queries. A network 
element which maintains a high number of parallel call 
legs needs a lot of resources. Additionally, in case of a 
failure in a network element, information is required about 
existing sessions. 

SUMMARY OF THE INVENTION 

[0010] It is therefore an object of the present i nvention 
to provide an efficient load control scheme for packet 
data networks. 

[001 1] This object is achieved by a method of control- 
ling processing load in a packet data network, said meth- 
od comprising the steps of: 

setting a load control information in a predetermined 
field of a message; 

routing said message through that packet data net- 
work; 

checking said load control information on the routing 
path of said message and/or on the routing path of 
a response message to said message; and 
selecting a processing resource of said packet data 
network in response to the result of said checking 
step. 

[0012] Furthermore, the above object is achieved by 
a network device for controlling processing load in a pack- 
et data network, said device comprising: 

checking means for checking a load control informa- 
tion provided in a predetermined field of a message 
or response message; and 
selecting means for selecting a processing resource 
for said message or response message in response 
to said checking means. 

[0013] Additionally, the above object is achieved by a 
device for transmitting a message to a packet data net- 
work, said device being arranged to set into a predeter- 
mined field of said message a load control information 
[0014] Moreover, the above object is achieved by a 
method of distributing load control information in a packet 
switched network, comprising the steps of: 

creating a first load control information For selecting 
processing resources of said packet data network in 
a first network element; 

setting said first load control information into a pre- 
determined field of a message; 
routing said message to a second network element; 
storing said first load control information in said sec- 
ond network element; 



creating a second toad control information For se- 
lecting processing resources of said packet data net- 
work in said second network element; 
setting said second load control information into a 
s predetermined field of a second message; 

routing said second message to said first network 
element; and 

storing said second load control information at said 
first network element. 

10 

[0015] In addition, the above object is achieved by a 
system for controlling processing load in a packet data 
network, said system comprising: 

15 - a first network element for setting a load control in- 
formation in a predetermined field of a message to 
be routed in said packet data network; and 
a second network element for checking said load 
control information on the routing path of said mes- 

20 sage; and for selecting a processing resource of said 
packet data network in response to the checking re- 
sult. 

[0016] Finally, the above object is achieved by a sys- 
25 tern for distributing load control information in a packet 
switched network, said system comprising: 

a first network element for creating a first load control 
information For selecting processing resources of 
so said packet data network and for setting said first 
load control information into a predetermined field of 
a message; and 

a second network element for receiving said mes- 
sage, for storing said first load control information, 

35 for creating a second load control information For 
selecting processing resources of said packet data 
network, for setting said second load control infor- 
mation into a predetermined field of a second mes- 
sage, and for routing said second load control infor- 

40 mation to said first network element; wherein said 
first network element is adapted to store said second 
load control information. 

[0017] Accordingly, load sharing or load balancing in- 
45 formation can be routed in messages to the respective 
network nodes or servers to thereby reduce the amount 
of resources required for the load control functionality. 
Moreover, information about existing sessions can be 
provided in case of failures of network elements. 
so [0018] The predetermined field may be a via branch 
of a SIP message. The load balancing information may 
be copied from another predetermined field to said pre- 
determined field. 

[001 9] The predetermined field may be a subfield of a 
55 user part of an address header, e.g. a URI of the SIP 
Route header. Thereby, additional information can be 
conveyed in the user part. In particular, company confi- 
dential information can be carried in one or more sub- 
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fields e.g. encrypted and/or tokenised and/or encoded 
information. Furthermore, routing inside a network ele- 
ment, e.g. choosing a correct call state model (for exam- 
ple for originating or terminating session/transaction 
case) can be conducted using the subfield or subfields s 
of the user part. The load control information and/or other 
control information may be a subscriber and/or service 
and/or server specific information carried in one or more 
subfields e.g. from an S-CSCF to an AS. Alternatively, 
an IP address may be carried in the subfield, which may w 
be an address of the host in the domain part. 
[0020] Thus, a plurality of subfields can be provided in 
the user part for conveying different types of said load 
control information and/or the other control information. 
In particular, the user part may be parsed and divided is 
into the subfields. Alternatively, at least one of structure, 
order and usage of the subfields may be predetermined, 
e.g. on a standardised basis. The subfields may be sep- 
arated by a predetermined bit string, character, character 
string, or other separator. 20 
[0021] The selection step may be used for load bal- 
ancing. A virtual address used for distributing the mes- 
sage to a predetermined processor node. The virtual ad- 
dress may be shared by a plurality of processor nodes. 
These processor nodes may have a call state control 25 
functionality of an IP-based cellular network. Thus, a 
mechanism to ensure even load balancing is provided, 
and a subscriber can be tied to as processor node for 
the whole registration period. By using a virtual address, 
a cluster itself can do load balancing for cluster nodes, so 
[0022] Additionally, the load control information may 
comprise a first port number indicating a first port for re- 
ceiving a request message. Furthermore, the load control 
information may comprise a second port number indicat- 
ing a second port for receiving a response message. 35 
Thereby, requests and responses can be received at the 
indicated port where a load balancing information is pro- 
vided. 

[0023] In another aspect, the load control information 
may comprise a first information and an optional second *o 
information. The first and optional second information 
may be set in a headerfield selected from a Route header 
field, Via header field, or Contact header field of a SIP 
message. The first information may indicate whether a 
session of the message already exists. The optional sec- 45 
ond information may then indicate an identification of the 
existing session. The first and second information may 
be a hidden information not meaningful to other networks. 
[0024] Accordingly two alternatives can be provided. 
In the first alternative, it is only detected whether the mes- 50 
sage is the first one in a call leg. Thereby, easy and fast 
recognition of the first message in a session can be pro- 
vided. No change to other network elements or terminals 
is required. The scheme may even be provided on a non- 
standardised basis. In the second alternative, an addi- 55 
tional session identification is detected based on the sec- 
ond information. Thereby, in addition to the above ad- 
vantages of the first alternative, easy and fast recognition 



of the session in question can be provided. 
[0025] In particular, the first and/or second information 
may be set as a part of user part in an address (e.g. SIP 
URI) of a header field, as a part of host name of a header 
field, as a part of domain name of a header field, as a 
parameter of the header field, as a port number of the 
header field, wherein the port number may be used for 
differentiating a first message from subsequent messag- 
es, or as an extension header field to the message. Al- 
ternatively, the first and/or second information may be 
set in a payload portion of the message. 
[0026] The second information may then be extracted 
in response to a detection of the first information, and 
may be used in the selection step. 
[0027] The network device for controlling the process- 
ing load may comprise a call state or call session control 
functionality of an IP-based cellular network. The select- 
ing means may be arranged to select a predetermined 
processor node to which said message is distributed. 
Thus, in addition to the virtual address, the load control 
information specifies the processor node. 
[0028] The selecting means may be arranged to initiate 
creation of a new session. 

[0029] The device for transmitting the message may 
also comprise call state control functionality or call ses- 
sion control functionality of the IP-based cellular network. 
This session control functionality may be a serving call 
session control functionality, an interrogating call session 
control functionality or a proxy call session control func- 
tionality. The device may be arranged to set the load 
control information in the user part of the header address 
of the message, or, alternatively, in a host name, domain 
name, header parameter, port number, or extension 
header field of a header portion or in a payload portion 
of the message. 

[0030] Other advantageous developments of the 
present invention are defined in the dependent claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0031] The present invention will now be described on 
a basis of preferred embodiments with reference to the 
accompanying drawings, in which: 

Fig.1 shows an IMS network architecture in which 
the present invention can be implemented; 

Fig. 2 shows a structure of an SIP URI according to 
the first preferred embodiment; 

Fig. 3 shows a signalling and processing diagram of 
a first signalling example according to the first pre- 
ferred embodiment; 

Fig 4 shows a processing and signalling diagram in- 
dicating a second signalling example according to 
the first preferred embodiment; 



4 



7 



EP 1 590 719 B1 



8 



Fig. 5 shows a signalling and processing diagram 
according to a second preferred embodiment; 

Fig. 6 shows a flow diagram of a first example of a 
load sharing mechanism according to the second 
preferred embodiment; and 

Fig. 7 shows a flow diagram of a second example of 
a load sharing mechanism according to the second 
preferred embodiment. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

[0032] The preferred embodiments will now be de- 
scribed on the basis of an IMS network architecture as 
shown in Fig. 1. 

[0033] It is noted that Fig. 1 only shows those IMS com- 
ponents required for a description of the present inven- 
tion. As an example, the radio access network and the 
core network are not shown in Fig. 1. According to Fig. 
1 , a terminal device or UE 10, which may be a mobile or 
cellular terminal device, is connected to a P-CSCF 20 
arranged in a visited domain 70 of the UE 10 and provid- 
ing basic IP connectivity and mobile management below 
it. The UE 1 0 uses SIP to communicate with the P-CSCF 
20 which is similar to a SIP proxy server. In the present 
case, the consumer or subscriber of the UE 1 0 is roaming 
in the visited domain 70 where the P-CSCF 20 is located. 
The role of the P-CSCF 20 is to provide emergency call 
and other such services requiring specific knowledge of 
the visited domain 70. Instead of radio access network 
also alternative access networks may be used. Instead 
of mobile or cellular terminal device also other kind of 
terminals may be used, especially in alternative access 
networks. 

[0034] Furthermore, an S-CSCF 40 is always located 
in the subscriber's or consumer's home domain 80 and 
takes the role of the SIP registrar and proxy servers, so 
that the UE 1 0 can be registered at the S-CSCF 40 using 
SIP via the P-CSCF 20. Furthermore, an l-CSCF 30 is 
provided as another SIP proxy server responsible mainly 
for finding the correct S-CSCF for a given subscriber or 
consumer. The S-CSCFs can be dynamically allocated 
per registration in order to achieve efficient load balanc- 
ing and error residency. An Application Server (AS) 60 
is provided as a SIP element dealing with the services 
provided to the UE 10. Separate ASs can be provided 
for different purposes. Finally, a Home Subscriber Server 
(HSS) 50 is arranged for profile management and au- 
thentication. 

[0035] In the following, a first preferred embodiment of 
the present invention will be described on the basis of 
Figs. 2 to 6. 

[0036] In the first preferred embodiment, a content of 
a user part of SIP URI is used for load control, e. g. ses- 
sion control and load balancing. In particular, the user 
part of the SIP URI (Uniform Resource Identifier) can be 
divided into subfields which may be utilized e.g. for con- 



trol and/or routing purposes. In SIP, the Route Header 
normally contains SIP URIs which have only a domain 
part, such that the user part is free to be used for other 
purposes. 

s [0037] Fig. 2 shows a schematic diagram indicating a 
structure of the FQDN or SIP URI 100 according to the 
first preferred embodiment. The SIP UR1 100 comprises 
a user part 120 and a domain part 140 separated by an 
"@" sign, similar to an e-mail address. The objects ad- 

10 dressed by SIP are users at hosts, identified by the SIP 
URI 100. The user part 120 is used for carrying a user 
name or a telephone number, while the host or domain 
part 140 carries either a domain name or a numeric net- 
work address. 

15 [0038] Due to the fact that the user part is not used in 
the Route header neither in the Via header, it can be 
divided into subfields 1 21 , 122, ...1 2n, which maybe sep- 
arated by a suitable separator 130, e.g. a bit string, char- 
acter or character string, wherein the characters can be 

20 printable and/or non-printable characters or bit strings. 
The order and usage of the subfields 121 to 12n can be 
predetermined or standardized if not considered as an 
implementation specific information. 
[0039] Regarding the arrangement and structure of the 

25 subfields 121 to 12n in the user part 120, three options 
may be used. 

[0040] According to the first option, the user part 120 
may be arranged as a single field, which contains the 
subfields 121 to 12n. This single field is then parsed and 

30 divided into the subfields 121 to 12n, when needed. This 
provides the advantage that no standardization is needed 
if the field is created and utilized inside the same network. 
[0041] According to the second option, the user part 
120 may structurally consist of the subfields 121 to 12n, 

35 while the syntax and possibly also the semantics of the 
subfields 121 to 12n are predefined or standardized. In 
this case, the subfields 121 to 12n can be created and 
utilized even in different networks. 
[0042] According to the third option, a combination of 

40 the first and second option may be used. 

[0043] The following is an example of the SIP UR1 100 
where a second subfield is used for signaling the session/ 
transaction case and a first subfield is used for signaling 
an implementation specific information. The separator 

45 1 30 is formed by the corrector 

57BC442C_terminating@s-cscf2.ims.sonera.fi 

[0044] Accordingly, "terminating" is signaled as the 
so session/transaction case and "57BC442C" is signaled 
as the implementation-specific information. 
[0045] In the following, first and second examples of a 
load control mechanism according to the first preferred 
embodiment are described with reference to Figs. 3 and 
55 4. 

[0046] The load control mechanism is provided to en- 
sure even load balancing if a network element or part is 
implemented by a number of processor nodes. In the IMS 
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network architecture according to Fig.1, the UE 10 has 
the P-CSCF 20 as a contact point to the network. Be- 
tween the UE 1 0 and the P-CSCF 20, an IP security func- 
tion IPSec is used for integrity and confidentiality protec- 
tion. Furthermore, a compression function may be used 
to compress the signaling information in the prefix or user 
part 120 of the FQDN or SIP URI 100 of the UE 10. In 
order to achieve high capacity and fast response times, 
the IPSec data and compression data of the particular 
subscriber of the UE 10 must be stored in a memory e.g. 
volatile memory or random access memory (RAM). As a 
result a subscriber should be tied to the processor node 
to which it is registered.By using the virtual address, only 
the node or server cluster itself can do load balancing for 
cluster nodes. 

[0047] Fig. 3 shows a signaling and processing dia- 
gram of a load control mechanism for distributing a load 
balancing information (LBI) upon registration of a user. 
Here, reasoning for load balancing is that e.g. compres- 
sion is done at distributed nodes. Therefore, in practice 
at the interface between the UE 10 and the P-CSCF 20 
load balancing cannot be done based on SIP level infor- 
mation since it is compressed. At this interface reason- 
able load balancing key is the IP-address of the UE 10. 
When a terminating attempt or request is received, which 
is targeted to the UE 1 0 it is essential that the terminating 
attempt is received at the same processing node to which 
messages from the UE 10 are distributed. Thereby, un- 
necessary hops can be avoided in the IP-based network. 
[0048] When the UE 1 0 transmits in step 1 a SIP Reg- 
ister message, the P-CSCF 20 creates and inserts in step 
2 a first load balancing information LBI(P-CSCF-I) to 
SIP-URL(P-CSCF) of the Path field of the header of that 
Register message. The first load balancing information 
LBI(P-CSCF-1 ) in the Path field will be received in future 
when an initial request is received from the S-CSCF 40. 
The P-CSCF 20 also creates and inserts a second load 
balancing information LBI(P-CSCF-2) to the Via branch 
at that Register message. The second load balancing 
information LBI(P-CSCF-2) at the Via branch will be re- 
ceived along with a response to that Register message. 
The first and second load balancing information LBI(P- 
CSCF-1) and LBI(P-CSCF-2) may be identical or differ- 
ent. The register message is routed in step 3 and 4 via 
the l-CSCF 30 to the S-CSCF 40. When the S-CSCF 40 
receives the Register message from the P-CSCF 20, it 
does load balancing in step 5 based on e.g. the Call ID. 
In step 6, the S-CSCF 40 then stores to a subscriber 
database the SIP-URL(P-CSCF).from the Path field, 
which contains the first load balancing information LBI 
(P-CSCF-1) of the P-CSCF 20. In step 7, the S-CSCF 
40 creates an own load balancing information LBI(S- 
CSCF-1) and inserts it to the SIP-URL(S-CSCF) of the 
Service-Route field of the SIP 200OK response message 
sent in steps 8 and 9 via the l-CSCF 30 to the P-CSCF 
20. This load balancing information LBI(S-CSCF-I) will 
be received in future when an initial request is received 
from the P-CSCF 20. In addition, the Via branch contains 



the SIP-URL(P-CSCF) of the P-CSCF 20 which has been 
copied from the Register message received after step 4. 
When the P-CSCF 20 receives this 200OK response 
message, load balancing can be done in step 10 based 

5 on the second load balancing information LBI(P-CSCF- 
2) obtained from the Via branch. In step 1 1 , the P-CSCF 
20 stores in a database the SIP-URL(S-CSCF) contain- 
ing the load balancing information LBI(S-CSCF-I) of the 
S-CSCF 40 obtained from the Service Route field of the 

10 200OK response message. Finally, in step 1 2, the 200OK 
response message indicating successful registration is 
forwarded to the UE 10. 

[0049] Accordingly, after the above procedure, the P- 
CSCF 20 has the SIP-URL(S-CSCF) at its subscriber 

is data which points to the S-CSCF 40 and which contains 
the corresponding load balancing information LBI(S- 
CSCF-1 ). Similarly, the S-CSCF 40 has the SIP-URL(P- 
CSCF) at its subscriber data which points to the P-CSCF 
20 and which contains the corresponding load balancing 

20 information LBI(P-CSCF-I). The load balancing informa- 
tion can thus be used later by the respective load bal- 
ancers of the P-CSCF 20 and the S-CSCF 40. For ex- 
ample, when a terminating attempt happens, the S-CSCF 
40 then fetches this load balancing information from the 

25 subscriber database and inserts it to the corresponding 
request. 

[0050] Fig. 4 shows a processing and signaling dia- 
gram of a load control mechanism for using the load bal- 
ancing information (LBI) when an initiation request is sent 

so to the network. When the UE 10 sends in step 1 a SIP 
Invite message to the P-CSCF 20, load balancing is done 
based on the IP address of the UE 10. In step 2, the P- 
CSCF 20 reads from the subscriber database the previ- 
ously stored SIP-URL(S-CSCF) to be used for routing 

35 the Invite message to the S-CSCF40 in step 3. Addition- 
ally, the SLP-URL(S-CSCF) is inserted to the topmost 
Route field, and the SIP-URL(P-CSCF) is inserted to the 
Record-Route field. Moreover, the first load balancing 
information LBI(P-CSCF-I) is inserted to the Via branch. 

40 When the Invite message is received at the S-CSCF 40, 
it obtains from the topmost Route field the SIP-URL(S- 
CSCF) which contains its previously set load balancing 
information LBI(S-CSCF-I). Based on this load balanc- 
ing information LBI(S-CSCF-I) load balancing is done in 

45 step 4 to find a correct computer. When the S-CSCF 40- 
sends the Invite message in step 5, it inserts the SIP- 
URL(S-CSCF) to the Record-Route field and inserts its 
load balancing information LBI(S-CSCF-I) to the Via 
branch. In step 6, the application server 60 responds with 

50 a 200OK response message comprising the load balanc- 
ing information LBI(P-CSCF-I) and LBI(S-CSCF-I) of 
the P-CSCF 20 and the S-CSCF 40 in the Via branch. 
When the S-CSCF 40 receives the 200OK response 
message, it obtains its load balancing information LBI(S- 

55 CSCF-1 ) from the Via branch and uses it for load balanc- 
ing in step 7. Similarly, when the P-CSCF 20 subsequent- 
ly receives the 2000K response message forwarded by 
the S-CSCF 40 in step 8, it obtains its first load balancing 
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information LBI(P-CSCF-1 ) from the Via branch and uses 
it for load balancing in step 9. In step 10, the 200OK 
message is forwarded the UE 10 to acknowledge the 
previous invite message. 

[0051] When the application server 60 sends in step 
11 a subsequent SIP request, e.g. an Invite message, 
within a dialog, it uses a Route list which it has previously 
created based on the Record-Route entries of the initial 
request, i.e. Invite message received after step 5. The 
topmost Route entry is the SIP-URL(S-CSCF) including 
the corresponding load balance information LBI(S- 
CSCF-1 ) therein. The second Route entry is the SIP-URL 
(P-CSCF) including the corresponding load balance in- 
formation LBI(P-CSCF-I) therein. When the S-CSCF 40 
receives the subsequent Invite message, it obtains from 
the topmost Route entry its load balancing information 
LBI(S-CSCF-I) which is inside the SIP-URL(S-CSCF). 
In step 12, the S-CSCF 40 does load balancing based 
on this load balancing information LBI(S-CSCF-I) and 
removes the Route entry pointing to itself. Now, the top- 
most Route entry points to the P-CSCF 20. In step 13, 
the subsequent Invite message is forwarded to the P- 
CSCF 20. When the P-CSCF 20 receives the subsequent 
Invite message, it obtains from the topmost Route entry 
its load balancing information LBI(P-CSCF-I) which is 
provided inside the SIP-URL(P-CSCF). Then, it does 
load balancing based on this load balancing information 
LBI(P-CSCF-I) in step 14, and removes the Route entry 
pointing to itself. Finally, in step 15, the Invite message 
is forwarded to the UE 10. 

[0052] In general, at the registration phase the path 
and load balancing information is recorded and stored to 
be used later for requests. The later request should con- 
tain this load balancing information and load balancing 
is then done based on that load balancing information. 
Accordingly, any load balancing information inserted dur- 
ing the registration phase is for future requests. 
[0053] In all cases, the via-branch parameter of the Via 
header field may be used to carry similar information used 
by the load balancing function to distribute responses to 
the correct processor node. 

[0054] Furthermore, different port numbers may be 
used to identify where the load balancing information can 
be found. In particular, during "path recording", the re- 
quest port is set to the domain part 140 of the SIP URI 
120. Thus, requests are then received at that request 
port and it is known where to read the load balancing 
information. Similar, "port" can be set for out going re- 
quests, such that responses are received at that port. 
[0055] In case of a load balancing function for an in- 
gress or incoming SIP traffic which is destined to the con- 
cerned network element, the destination IP address is 
checked whether it is a virtual IP address or not. If not, 
load balancing is not needed, e.g. normal L3 routing can 
then be applied for packet. If the destination iP address 
is a virtual IP address, then load balancing is needed. 
There are two choices, i.e., the virtual IP address can be 
either a P-CSCF address or it can be an S-CSCF or I- 



CSCF address. A corresponding destination port infor- 
mation is used to detect the kind and location of the load 
balancing information. Then, load balancing is done 
based on the load balancing information and the resulting 
5 output corresponds to the correct processing node to 
where packets should be forwarded. The load balancing 
information may be a call id, UE-IP-address, or a previ- 
ously generated load balancing information. 
[0056] In case of an egress or outgoing traffic which is 

10 originated from the concerned network element, the 
source IP-address is checked whether it is one of the 
virtual IP-addresses (P-CSCF, S-CSCF or l-CSCF) of 
the CPS. If not, then normal routing happens. If yes, it is 
checked if it is a Loop address. If so, the transport protocol 

is is determined and subsequently the destination port is 
checked to determine a request port or dedicated port. 
Based on the checking result a procedure for obtaining 
the load balancing information and forwarding the IP 
packet is selected. In case of a Not-Loop Address, the 

20 source IP-address is again checked to determine wheth- 
er it is an S-CSCF/I-CSCF address or a P-CSCF address. 
If it is an S-CSCF/I-CSCF address, the transport protocol, 
i.e. Transmission Control Protocol (TCP) or User Data- 
gram Protocol (UDP), is determined. If TCP is indicated, 

25 the SIP message is reassembled after buffering and then 
forwarded. If UDP is indicated, the IP packet can be di- 
rectly forwarded. If it is P-CSCF address, the source port 
is determined. If a Client port or Request port is indicated, 
the transport protocol is determined and the above 

30 processing is again initiated. In case a UE unsecure/se- 
cure client/server port is indicated, the IP packet is di- 
rectly forwarded by an L3 (Protocol Layer 3) procedure. 
[0057] In the following, the second preferred embodi- 
ment of the present invention is described with reference 

35 to Figs. 5 to 7. The second preferred embodiment is di- 
rected to a load sharing mechanism for discovering in an 
efficient way which SIP traffic belongs to which session, 
and whether a request, e.g. a SIP INVITE request, is an 
initial request or a re-request. 

40 [0058] Fig. 5 shows a processing and signaling dia- 
gram indicating a first example of the load sharing mech- 
anism according to the second preferred embodiment. 
The mechanism of the first example is adapted to detect, 
whether a SIP request, e.g. SIP INVITE is the first one 

45 in a call leg. This is achieved by providing a hidden in- 
formation in the Record-Route header field of the SiP 
request. 

[0059] Whenever a session-stateful CSCF, e.g. the S- 
CSCF 40 in Fig. 1, receives a SIP request and inserts a 

50 Record-Route header field (step 1 ), it inserts a hidden 
indication into the Record-Route header field (step 2), 
and forwards the SIP request with the hidden indication 
towards the destination address. In the present case, 
"hidden" means that the indication is not meaningful to 

55 other networks, e.g. networks outside the network where 
the indication is set. However, if required, the added in- 
dication may as well be a standardized information read- 
able by other networks. 
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[0060] Then, whenever an INVITE arrives, a session- 
stateful CSCF checks, whether the topmost Route head- 
er field or request URI (if there is no Route header) con- 
tains such a hidden information. The Route header field 
is constructed from the Record-Route header field. If the 5 
hidden information or indication is present, the session 
is already existing. If not, a new session has to be created 
internally in the concerned session-stateful CSCF. 
[0061] As SIP responses (e.g. 200 OK) in normal case 
belong to an existing session, they don't need to be dis- '0 
tinguished. 

[0062] The indication can be part of the hostname. As 
an example, it is assumed the default routing address to 
this element would be <scscf17.operator.net> such as 
<B@provider.net; maddr=scscf17.operator.net>, the 15 
Record-Route could then look like: 

RecordRoute: <B@provider.net; maddr=ex- 
ist.scscf17.operator.net> 

20 

or 

Record-Route: <B@exist.provider.net> 

or 25 

Record-Route: 

<B@existscscf17 .operator.net>. 

[0063] Here the hidden indication would be "exist." as 30 
part of the hostname. The user part 120 may be empty 
in these examples. E.g., instead of <B@ex- 
ist.scscfl 7. operator.net> the following may be used: 
<existscscf17.operator.net>. The Route header field 
is constructed from the Record-Route header field. For 35 
example: 

Record-Route: <B@exist.scscf1 7. operator. net> 

gives 40 

Route: <B@ exist .scscf17.operator.net>. 

[0064] As an alternative, the S-CSCF 40 may add an 
"rr-param" to the Record-Route header field as defined 45 
in RFC3261: 

Record-Route = "Record-Route" HCOLON rec- 
route '(COMMA rec-route) 

rec-route = name-addr *(SEMI rr-param) 50 

rr-param = generic-param 

generic-param = token [EQUAL gen-value] 

gen-value =tokenlhost/quoted-string 

token = 1*(alphanum/"-" I "." / "/""%" / "*" 

/ "_" / "+" / / / "~" ) 55 

Route - "Route" HCOLON route-param '(COMMA 

route-param) 

route-param = name-addr *( SEMI rr-param) 



[0065] A corresponding example may look as follows: 

RecordRoute: <B@provider.net; maddr= 
scscf17.operator.net; existing > 

or 

Record-Route: <B@proyider.net ; existing> 

or 

Record-Route: <B@scscf 17.operator.net; exist- 
ing^ 

[0066] Again, the user part 120 may be empty. The 
Route header field is constructed from the Record-Route 
header field. 

[0067] If the rr-param "existing" is received, it can eas- 
ily be detected that the request belongs to an existing 
session. 

[0068] According to a further alternative, different port 
numbers may be used for the first and for the subsequent 
requests. As an example, it is assumed that the default 
routing to the concerned element or node would be 
<B@provider.net; maddr=scscf17.operator.net>. Then, 
the RecordRoute entry could look like : 

RecordRoute: <B@provider.net; maddr= 
scscfl 7. operator. net :19373 > 

or 

Record-Route: <B@provider.net:19373> 

or 

Record-Route: <B@scscf 17.operator.net: 
19373 >. 

[0069] And here again, the user part 120 may be emp- 
ty. The Route header field is constructed from the 
Record-Route header field. For example 

Record-Route: <B@provider.net; maddr= 
scscfl 7. opera tornet :19373> 

gives 

Route : <B@provlder.net; maddr= scscf17.op- 
erator.net :19373 >. 

[0070] All the requests, which arrive at port 19373, 
would be recognized as belonging to an existing session. 
[0071] According to another alternative, a new propri- 
etary or non-standardized extension header field may be 
used in SIP to convey the information. An example of the 
new header entry may look as follows: 
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CSCF-session: existing in scscf17.operator.net 

[0072] However, in this case, the UA would have to 
support this feature, i.e. copying this new header field 
from the SIP requests to the SIP responses and subse- 
quent SIP requests. 

[0073] According to a still other alternative, the payload 
portion of the SIP request could be used for conveying 
the hidden indication. 

[0074] Fig. 6 shows a schematic flow diagram indicat- 
ing the load sharing mechanism according to the first 
example. When an initial request is handled by the ele- 
ment, Record-Route header can be inserted to the re- 
quest before sent out. To this Record-Route header a 
hidden information can be added. Later these Record- 
Route headers are passed back within response to the 
originator of the request. When the originator gets this 
response, it gets those Record-Route headers and cop- 
ies them to the Route list. When the originator sends 
subsequent request, it takes this Route list and inserts 
all entries to the subsequent request as Route headers. 
Now subsequent request can be sent out. When the next 
server receives this request, it can find from the Route 
header same SIP URI it inserted earlier to initial request. 
A Via header is also inserted to the request. Same Via 
header is received in the response to the request, and 
hidden information in the Via header can be used to find 
the instance or element to which the response must be 
passed. 

[0075] Thus, according to Fig. 6, if a SIP request is 
received, the Route header field, or new header field or 
payload portion, is checked for the hidden indication (step 
S201). If a hidden indication is detected in step S202, a 
session is already existing and no creation is required 
and the request can be allocated to the call leg of the 
existing session (step S204). On the other hand, if no 
hidden indication is detected, a new session is created 
in step S203. 

[0076] According to the second example of the load 
sharing mechanism, an internal session identifier (ISId) 
is detected based on the hidden indication. This alterna- 
tive includes the above mechanism of the first example, 
i.e. if the ISId cannot be discovered, we can assume, that 
the request belongs to a new call leg. 
[0077] In the second example, a hidden indication is 
provided e.g. in the Record-Route header field and in the 
Via header field of the SIP request. 
[0078] Thus, referring to Fig. 5, whenever a session- 
stateful CSCF, e.g. the S-CSCF 40, inserts a Record- 
Route or Via header field, it will add a hidden indication, 
containing information about the internal session identi- 
fier (ISId). 

[0079] Fig. 7 shows a schematic flow diagram indicat- 
ing the enhanced load sharing mechanism according to 
the second example. Whenever a message arrives, it is 
checked whether the message corresponds to a SIP re- 
quest (step S301). If so, the session-stateful CSCF 
checks in step S303 whether the topmost Route header 



field contains a hidden indication. If it is determined in 
step S305 that the hidden indication is present, the ses- 
sion is existing and the ISId can be extracted to provide 
a fast session recognition and allocation function (step 
5 S307). If not, a new session has to be created in step 
S306. 

[0080] If no SIP request is detected in step S301 , it is 
checked in step S302 whether the message corresponds 
to a SIP response. If so, the session-stateful CSCF 

10 checks in step S304 whether the topmost Via header 
field contains a hidden indication. If it is determined in 
step S305 that the hidden indication is present, the ses- 
sion-stateful CSCF extracts the ISID from the topmost 
Via header field of the SIP response (step S307). 

is [0081] Hence, even a quick identification of an existing 
session can be provided at the CSCFs. 
[0082] As in the first example, the hidden indication 
can be part of the hostname. As an example, it is as- 
sumed that the default routing to this element would be 

20 <scscf 17. operator. net> such as <B@provider.net; mad- 
dr=scscf17.operator.net>. Then, the Route header field 
could look like the following. The Route header field is 
constructed from the Record-Route header field. 

25 Route: <B@provider.net; maddr =ISId224497 . 
scscf "i7.operator.net> 

or 

so Route: <B@ISId224497provider.net> 

or 

Route: <B@JSId224497.scscf17.operator.net>. 

35 

[0083] Here, the ISId is "224497" as part of the host- 
name. The user part 120 may be empty. 
[0084] Similarly, the Via header field could be used, 
which could then look like: 

40 

Via: SIPI2.0IUDP ISId224497 . scsci '17. operator. 
net:S060 

[0085] All the SIP responses which contain 
45 "lSld224497" as part of the hostname, belong the same 
existing session. 

[0086] As an option, the ISId as part of the hostname 
could also be encrypted/tokenized for hiding or redun- 
dancy purposes. 
50 [0087] As an alternative, the S-CSCF 40 may add a 
"rr-param" to the Record-Route header field as defined 
in RFC3261. 

[0088] Similarly, this works for SIP responses, where 
the Via header field would be extended by a "via-exten- 
55 sion" as defined in RFC3261 : 

Via = ("Via" I "v") HCOLON via-parm '(COMMA via- 
parm) 
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via-parm = sent-protocol LWS sent-by*( SEMI via- 
params ) 

via-params via-ttll via-maddr 

I via-received I via-branch 

I via-extension 5 
via-ttl - "til" EQUAL til 
via-maddr = "maddr" EQUAL host 
via-received = "received" EQUAL (IPv4address I 
IPv6address) 

via-branch = "branch" EQUAL token to 
via-extension = generic-param 
sent-protocol = protocol-name SLASH protocol-ver- 
sion 

SLASH transport 
protocol-name = "SIP"I token 15 
protocol-version = token 
transport = "UDP" I "TCP" I "TLS"I "SCTP" 

I other-transport 
sent-by = host [COLON port] 

til = V3DIGIT ; 0 to 255 20 
generic-param = token [ EQUAL gen-value ] 
gen-value = token I host I quoted-string 
token = 1 "(alphanuml "-"I ". "I Tl"%"l "*" 
I "_" / "+" / / / "~" ) 

25 

[0089] As an example, the Route header field could 
then look like the following. The Route header field is 
constructed from the Record-Route header field. 

Route: <B@proivider.net;maddr=scscf17.oper- 30 
ator.net; ISId=224497> 

or 

Route:<B@provider.net; ISId=224497 >. 35 



routing to the concerned element would be <B@provid- 
er.net; maddr=scscf17.operator.net>, the Route header 
field could then look like the following. The Route header 
field is constructed from the Record-Route header field. 

Route: <B@provider.net; maddr= scscf17.oper- 
ator.net : 224497> 

or 

Route: <B@provider.net: 224497> 

or 

Route: <B@scscf17.operator.net: 224497>. 

[0096] User part may be empty. All the SIP requests, 
which arrive e.g. at port 224497, then belong the same 
existing session. 

[0097] Similarly, this works for the Via header field, 
which could look like: 

Via: SIPI2.0IUDP scscf17.operator.net: 224497 

[0098] Here, all the SIP responses, which arrive at port 
224497, belong the same existing session. 
[0099] However, listening to many ports in parallel 
might cause performance or scalability problems. 
[01 00] As another alternative, a new proprietary exten- 
sion headerfield may be used in SIP to convey the hidden 
information. As an example, the new extension header 
field may look like: 

CSCF-session: "ISId=224497 in scscf17.opera- 
tor.net" 



or 

Route: <B@scscf17.operator.net; ISId= 

224497>. 40 

[0090] Here, the ISID is "224497" as parameter of the 
Route header field. 

[0091] The corresponding Via header field could then 
look like: "5 

Via: SIPI2.0IUDP scscf17.operator.net:5060; 
ISId=224497. 

[0092] In this case, all the SIP responses which contain 50 
the parameter "ISId=224497" belong to the same existing 
session. 

[0093] Optionally, the ISId as part of the hostname 
could also be encrypted/tokenized for hiding or redun- 
dancy purposes. 55 
[0094] According to a further alternative, different port 
numbers may be used for all existing sessions: 
[0095] As an example, it is assumed that the default 



[0101] However, as already mentioned in connection 
with the first example, the UA would have to support this 
feature, i.e. copying this new header field from the SIP 
requests to the SIP responses and subsequent SIP re- 
quests. 

[01 02] As a still further alternative, the payload portion 
of the SIP request or response could be used for this too. 
[0103] Mainly, the above load sharing mechanisms are 
provided in CSCFs or other network nodes with corre- 
sponding functionality. However, in general, they may 
also be implemented in terminal devices, such as the UE 
10. 

[0104] It is noted that the present invention is not re- 
stricted to the preferred embodiments described above. 
The present invention may be implemented in any net- 
work node having a load control functionality in any net- 
work. In particular, any header or payload fields of any 
packet data message or datagram may be used. Further- 
more, any information usable for load control can be con- 
veyed. The embodiments may thus vary within the scope 
of the attached claims. 
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Claims 

1. A method of controlling processing load in a packet 
data network, said method comprising the steps of: 

5 

a) setting a load control information in a prede- 
termined field (121 to 12n) of a message; 

b) routing said message in said packet data net- 
work; 

c) checking said load control information on the »o 
routing path of said message; and 

d) selecting a processing resource of said pack- 
et data network in response to the result of said 
checking step. 

15 

2. A method according to claim 1 , wherein said prede- 
termined field is a subfield (1 21 to 1 2n) of a user part 
(120) of an address header (100). 

3. A method according to claim 1 , wherein said prede- 20 
termined field is a via branch of a SIP message. 

4. A method according to claim 3, further comprising 
the step of copying said load control information from 
another predetermined field to said predetermined 25 
field. 

5. A method according to claim 2, wherein said address 
header is an URI (100) of a SIP Route header. 

30 

6. A method according to claim 2 or 5, further compris- 
ing the step of providing a plurality of subfields (121 
to 12n) in said user part (120) for conveying different 
types of said load control information. 

35 

7. A method according to claim 6, wherein said user 
part (120) is parsed and divided into said subfields 
(121 to 12n). 

8. A method according to claim 6, wherein at least one 
of structure, order and usage of said subfields (121 
to 12n) is predetermined. 

9. A method according to any one of claims 6 to 8, 
wherein said subfield (121 to 12n) are separated by 45 
a predetermined bit string, character, or character 
string. 

10. A method according to claim 1 , wherein a virtual ad- 
dress is shared by a plurality of processor nodes. 50 

11. A method according to claim 1 0, wherein said proc- 
essor node has a call state control functionality of an 
IP- based cellular network. 

55 

12. A method according to any one of claims 2 to 11, 
wherein said load control information comprises a 
first port number indicating a first port for receiving 



a request message. 

13. A method according to any one of claims 2 to 12, 
wherein said load control information comprises a 
second port number indicating a second port for re- 
ceiving a response message. 

14. A method according to claim 1, wherein said load 
control information comprises a first information in- 
dicating whether a session of said message is al- 
ready existing. 

15. A method according to claim 14, wherein said load 
control information comprises a second information 
indicating an identification of said existing session. 

16. A method according to claim 14 or 15, wherein said 
load control information is stored in a Route header 
field, a Via header field, or a Contact header field of 
a SIP message. 

17. A method according to any one of claims 14 to 16, 
wherein said load control information is a hidden in- 
formation not meaningful to other networks. 

18. A method according to any one of claims 14 to 17, 
wherein said load control information is set as a part 
of a host name of a header field. 

19. A method according to any one of claims 14 to 17, 
wherein said load control information is set as a pa- 
rameter of a header field. 

20. A method according to any one of claims 14 to 17, 
wherein said load control information is set as a port 
number of a header field. 

21 . A method according to claim 20, wherein said port 
number is used for differentiating a first message 
from subsequent messages. 

22. A method according to any one of claims 14 to 17, 
wherein said load control information is set as an 
extension header field to a header field. 

23. A method according to any one of claims 14 to 17, 
wherein said load control information is set in a pay- 
load portion of said message. 

24. A method according to claim 1 5, further comprising 
the steps of extracting said second information in 
response to a detection of said first information, and 
using said second information for said selection step. 

25. A method of distributing load control information in 
a packet switched network, comprising the steps of: 

a) creating a first load control information for se- 
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lecting processing resources of said packet net- 
works in a first network element (20); 

b) setting said first load control information into 
a predetermined field of a message; 

c) routing said message to a second network 
element (40); 

d) storing said first load control information in 
said second network element; 

e) creating a second load control information for 
selecting processing resources of said packet 
networks in said second network element; 

f) setting said second load control information 
into a predetermined field of a second message; 

g) routing said second message to said first net- 
work element and; 

h) storing said second load control information 
at said first network element. 

26. A network device for controlling processing load in 
a packet data network, said device (20, 40) compris- 
ing: 

a) checking means for checking a load control 
information provided in a predetermined field 
(121 to 12n) of a message; 

b) selecting means for selecting a processing 
resource for said message in response to said 
checking means. 

27. A network device according to claim 26, wherein said 
network device (20, 40) comprises a call state control 
functionality of an IP-based cellular network. 

28. A network device according to claim 26 or 27, where- 
in said selecting means is arranged to select a pre- 
determined processor node to which said message 
is distributed. 

29. A network device according to claim 26 or 27, where- 
in said selecting means is arranged to initiate crea- 
tion of a new session. 

30. A network device according to claim 29, wherein said 
load control information comprises a first information 
indicating whether a session of said message is al- 
ready existing. 

31 . A network device according to claim 30, wherein said 
load control information comprises a second infor- 
mation for identifying said existing session. 

32. A device for transmitting a message to a packet data 
network, said device (10, 20, 40) being arranged to 
set into a predetermined field (121 to 12n) of said 
message a load control information for selecting 
processing resources of said packet data network. 

33. A device according to claim 32, wherein said device 



comprises a call state control functionality of an IP- 
based cellular network. 

34. A device according to claim 33, wherein said call 
s state control functionality is a serving call state con- 
trol functionality or a proxy call state control function- 
ality. 

35. A device according to any one of claims 32 to 34, 
10 wherein said device is arranged to set said load con- 
trol information in a user part (120) of a header ad- 
dress (100) of said message. 

36. A device according to claim 35, wherein said header 
is address is a SIP URI (100). 

37. A device according to any one of claims 32 to 34, 
wherein said device is arranged to set said load con- 
trol information in a host name, a header parameter, 

20 a port number, or an extension headerfield of a head- 
er portion of said message, or in a payload portion 
of said message. 

38. A device according to claim 37, wherein said load 
25 control information comprises a first information in- 
dicating whether a session of said message is al- 
ready existing. 

39. A device according to claim 38, wherein said load 
30 control information comprises a second information 

indicating said existing session. 

40. A system for controlling processing load in a packet 
data network, said system comprising: 

35 

a) a first network element (10, 20, 40) arranged 
for setting a load control information in a prede- 
termined field (121 to 12n) of a message to be 
routed in said packet data network; and 
to b) a second network element (20, 40) arranged 

for checking said load control information on the 
routing path of said message; and for selecting 
a processing resource of said packet data net- 
work in response to the checking result. 

45 

41. A system for distributing load control information in 
a packet switched network, said system comprising: 

a) a first network element (20) arranged for cre- 

50 ating a first load control information for selecting 

processing resources of said packet network 
and for setting said first load control information 
into a predetermined field of a message; and 

b) a second network element (40) arranged for 
55 receiving said message, forstoring said first load 

control information, for creating a second load 
control information for selecting processing re- 
sources of said packet network, for setting said 
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second load control information into a predeter- 
mined field of a second message, and for routing 
said second load control information to said first 
network element; 

c) wherein said first network element (20) is 5 
adapted to store said second load control infor- 
mation. 

42. A system according to claim 40 or 41 , wherein said 
first and second network devices comprise a call 10 
state control functionality. 



Patentanspriiche 

15 

1 . Verfahren zum Steuern der Verarbeitungslast in ei- 
nem Paketdatennetzwerk, wobei das Verfahren die 
Schritte umfasst: 

a) Einstellen einer Laststeuerinformation in ei- 20 
nem vorbestimmten Feld (121 bis 12n) einer 
Nachricht; 

b) Leiten der Nachricht in dem Paketdatennetz- 
werk; 

c) Prufen der Laststeuerinformation auf dem 25 
Leitweg der Nachricht; und 

d) Auswahlen einer Verarbeitungsressource 
des Paketdatennetzwerks im Ansprechen auf 
das Ergebnis des Prufschritts. 

30 

2. Verfahren nach Anspruch 1 , wobei das vorbestimm- 
te Feld ein Unterfeld (121 bis 12n) eines Nutzerteils 
(120) eines Adresskopfs (100) ist. 

3. Verfahren nach Anspruch 1 , wobei das vorbestimm- 35 
te Feld ein Via-Zweig einer SIP-Nachricht ist. 

4. Verfahren nach Anspruch 3, des weiteren umfas- 
send den Schritt des Kopierens der Laststeuerinfor- 
mation von einem anderen vorbestimmten Feld in *o 
das vorbestimmte Feld. 

5. Verfahren nach Anspruch 2, wobei der Adresskopf 
eine URI (100) eines SIP-Route-Kopfes ist. 

45 

6. Verfahren nach Anspruch 2 oder 5, des weiteren um- 
fassend den Schritt des Bereitstellens einer Vielzahl 
von Unterfeldern (121 bis 12n) in dem Nutzerteil 
(120) zum Befordern von verschiedenen Arten der 
Laststeuerinformation. so 

7. Verfahren nach Anspruch 6, wobei der Nutzerteil 
(1 20) interpretiert und in die Unterfelder (121 bis 1 2n) 
aufgeteilt wird. 

55 

8. Verfahren nach Anspruch 6, wobei zumindest eines 
von Struktur, Reihenfolge und Nutzung der Unterfel- 
der (121 bis 12n) vorbestimmt ist. 



9. Verfahren nach einem der Anspruche 6 bis 8, wobei 
die Unterfelder (1 21 bis 1 2n) durch eine vorbestimm- 
te Bit-Folge, ein Zeichen oder eine Zeichenfolge ge- 
trennt sind. 

10. Verfahren nach Anspruch 1, wobei eine virtuelle 
Adresse von einer Vielzahl von Prozessorknoten ge- 
meinsam genutzt wird. 

11. Verfahren nach Anspruch 10, wobei der Prozessor- 
knoten eine Gesprachszustandssteuerfunktionalitat 
eines IP-basierten zellularen Netzwerks aufweist. 

12. Verfahren nach einem der Anspruche 2 bis 1 1 , wobei 
die Laststeuerinformation eine erste Port-Nummer 
aufweist, die einen ersten Port zum Empfangen einer 
Anfragenachricht angibt. 

1 3. Verfahren nach einem der Anspruche 2 bis 1 2, wobei 
die Laststeuerinformation eine zweite Port-Nummer 
aufweist, die einen zweiten Port zum Empfangen ei- 
ner Antwortnachricht angibt. 

14. Verfahren nach Anspruch 1, wobei die Laststeuer- 
information eine erste Information aufweist, die an- 
gibt, ob eine Session der Nachricht bereits existiert. 

15. Verfahren nach Anspruch 14, wobei die Laststeuer- 
information eine zweite Information umfasst, die eine 
Identifikation der existierenden Session angibt. 

16. Verfahren nach Anspruch 14 oder 15, wobei die 
Laststeuerinformation in einem Route-Kopffeld, ei- 
nem Via-Kopffeld oder einem Contact-Kopffeld einer 
SIP-Nachricht gespeichert wird. 

17. Verfahren nach einem der Anspruche 14 bis 16, wo- 
bei die Laststeuerinformation eine fur andere Netz- 
werke bedeutungslose versteckte Information ist. 

18. Verfahren nach einem der Anspruche 14 bis 17, wo- 
bei die Laststeuerinformation als Teil eines Host-Na- 
mens eines Kopffelds festgelegt wird. 

19. Verfahren nach einem der Anspruche 14 bis 17, wo- 
bei die Laststeuerinformation als ein Parameter ei- 
nes Kopffelds festgelegt wird. 

20. Verfahren nach einem der Anspruche 14 bis 1 7, wo- 
bei die Laststeuerinformation als eine Port-Nummer 
eines Kopffelds festgelegt wird. 

21. Verfahren nach Anspruch 20, wobei die Port-Num- 
mer zur Unterscheidung einer ersten Nachricht von 
nachfolgenden Nachrichten verwende wird. 

22. Verfahren nach einem der Anspruche 14 bis 17, wo- 
bei die Laststeuerinformation als ein Erweiterungs- 
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kopffeld zu einem Kopffeld festgelegt wird. 

23. Verfahren nach einem der Anspruche 1 4 bis 1 7, wo- 
bei die Laststeuerinformation in einem Nutzlastab- 
schnitt der Nachricht eingestellt wird. 

24. Verfahren nach Anspruch 15, des weiteren umfas- 
send die Schritte des Extrahierens der zweiten In- 
formation im Ansprechen auf eine Erfassung der er- 
sten Information und Nutzens der zweiten Informa- 
tion fur den Auswahlschritt. 

25. Verfahren zum Verteilen einer Laststeuerinformati- 
on in einem paketvermittelten Netzwerk, mit den 
Schritten: 

a) Erzeugen einer ersten Laststeuerinformation 
zum Auswahlen von Verarbeitungsressourcen 
des Paketnetzwerks in einem ersten Netzele- 
ment (20); 

b) Einstellen der ersten Laststeuerinformation 
in ein vorbestimmtes Feld einer Nachricht; 

c) Leiten der Nachricht zu einem zweiten Netz- 
element (40); 

d) Speichern der ersten Laststeuerinformation 
in dem zweiten Netzelement; 

e) Erzeugen einer zweiten Laststeuerinformati- 
on zum Auswahlen von Verarbeitungsressour- 
cen des Paketnetzwerks in dem zweiten Netz- 
element; 

f) Einstellen der zweiten Laststeuerinformation 
in einem vorbestimmten Feld einer zweiten 
Nachricht; 

g) Leiten der zweiten Nachricht zu dem ersten 
Netzelement; und 

h) Speichern der zweiten Laststeuerinformation 
an dem ersten Netzelement. 

26. Netzwerkvorrichtung zum Steuern einer Verarbei- 
tungslast in einem Paketdatennetzwerk, wobei die 
Vorrichtung (20, 40) umfasst: 

a) Prufmittel zum Prufen einer in einem vorbe- 
stimmten Feld (1 21 bis 1 2n) einer Nachricht be- 
reitgestellten Laststeuerinformation; 

b) Auswahlmittel zum Auswahlen einer Verar- 
beitungsressource fur die Nachricht im Anspre- 
chen auf das Prufmittel. 

27. Netzwerkvorrichtung nach Anspruch 26, wobei die 
Netzwerkvorrichtung (20, 40) eine Gesprachszu- 
standssteuerfunktionalitat eines IP-basierten zellu- 
laren Netzwerks umfasst. 

28. Netzwerkvorrichtung nach Anspruch 26 Oder 27, wo- 
bei das Auswahlmittel ausgestaltet ist zum Auswah- 
len eines vorbestimmten Prozessorknotens, zu dem 
die Nachricht verteilt wird. 



29. Netzwerkvorrichtung nach Anspruch 26 oder 27, wo- 
bei das Auswahlmittel ausgestaltet ist zum Initiieren 
eines Aufbaus einer neuen Session. 

s 30. Netzwerkvorrichtung nach Anspruch 29, wobei die 
Laststeuerinformation einer erste Information um- 
fasst, die angibt, ob eine Session der Nachricht be- 
reits existiert. 

10 31 . Netzwerkvorrichtung nach Anspruch 30, wobei die 
Laststeuerinformation eine zweite Information zum 
Identifizieren der bestehenden Session umfasst. 

32. Vorrichtung zum Obertragen einer Nachricht zu ei- 
15 nem Paketdatennetzwerk, wobei die Vorrichtung 

(10, 20, 40) ausgestaltet ist, zum Einstellen einer 
Laststeuerinformation zum Auswahlen von Verar- 
beitungsressourcen des Paketdatennetzwerks, in 
einem vorbestimmten Feld (121 bis 12n) der Nach- 
20 richt. 

33. Vorrichtung nach Anspruch 32, wobei die Vorrich- 
tung eine Gesprachszustandssteuerfunktionalitat 
eines IP-basierten zellularen Netzwerks umfasst. 

25 

34. Vorrichtung nach Anspruch 33, wobei die 
Gesprachszustandssteuerfunktionalitat eine bedie- 
nende Anrufzustandsteuerfunktionalitat oder eine 
Proxy-Anrufzustandsteuerfunktionalitat ist. 

30 

35. Vorrichtung nach einem der Anspruche 32 bis 34, 
wobei die Vorrichtung ausgestaltet ist zum Einstellen 
der Laststeuerinformation in einem Nutzerteil (120) 
einer Kopfadresse (100) der Nachricht. 

35 

36. Vorrichtung nach Anspruch 35, wobei die Kopf- 
adresse eine SIR URI (100) ist. 

37. Vorrichtung nach einem der Anspruche 32 bis 34, 
4 o wobei die Vorrichtung ausgestaltet ist zum Einstellen 

der Laststeuerinformation in einem Host-Namen, ei- 
nem Kopfparameter, einer Port-Nummer oder einem 
Erweiterungskopffeld eines Kopfteils der Nachricht 
oder in einem Nutzlastabschnitt der Nachricht. 

45 

38. Vorrichtung nach Anspruch 37, wobei die Laststeu- 
erinformation eine erste Information aufweist zum 
Angeben, ob eine Session der Nachricht bereits exi- 
stiert. 

50 

39. Vorrichtung nach Anspruch 38, wobei die Laststeu- 
erinformation eine zweite Information umfasst, die 
die existierende Session angibt. 

55 40. System zum Steuern einer Verarbeitungslast in ei- 
nem Paketdatennetzwerk, wobei das System um- 
fasst: 
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a) ein erstes Netzwerkelement (1 0, 20, 40) zum 
Einstellen einer Laststeuerinformation in einem 
vorbestimmten Feld (121 bis 12n) einer in dem 
Paketdatennetzwerk zu leitenden Nachricht; 
und 5 

b) ein zweites Netzwerkelement (20, 40) zum 
Priifen der Laststeuerinformation auf dem Leit- 
weg der Nachricht und zum Auswahlen einer 
Verarbeitungsressource des Paketdatennetz- 
werks im Ansprechen auf das Prufergebnis. 10 



41 . System zum Verteilen einer Laststeuerinformation 
in einem paketvermittelten Netzwerk, wobei das Sy- 
stem umfasst: 

15 

a) ein erstes Netzwerkelement (20) zum Erzeu- 
gen einer ersten Laststeuerinformation zum 
Auswahlen von Verarbeitungsressourcen des 
Paketnetzwerks und zum Einstellen der ersten 
Laststeuerinformation in einem vorbestimmten 20 
Feld einer Nachricht; 

b) ein zweites Netzwerkelement (40) zum Emp- 
fangen der Nachricht, zum Speichern der ersten 
Laststeuerinformation, zum Erzeugen einer 
zweiten Laststeuerinformation zum Auswahlen 25 
von Verarbeitungsressourcen des Paketnetz- 
werks, zum Einstellen der zweiten Laststeuer- 
information in einem vorbestimmten Feld einer 
zweiten Nachricht, und zum Leiten der zweiten 
Laststeuerinformation zu dem ersten Netzwer- so 
kelement; 

c) wobei das erste Netzwerkelement (20) aus- 
gestaltet ist zum Speichern der zweiten Last- 
steuerinformation. 

35 

42. System nach Anspruch 40 oder 41 , wobei das erste 
und zweite Netzwerkelement eine Gesprachszu- 
standssteuerfunktionalitat aufweisen. 



Revendications 

1. Procede de controle d'une charge de traitement 
dans un reseau de donnees par paquets ; ledit pro- 
cede comprenant les etapes consistant a : 45 



2. Procede selon la revendication 1 , dans lequel ledit 
champ predetermine est un sous-champ (121 a 12n) 
d'une partie utilisateur (120) d'un en-tete d'adresse 
(100). 

3. Procede selon la revendication 1, dans lequel ledit 
champ predetermine est une branche de liaison d'un 
message SIP. 

4. Procede selon la revendication 3, comprenant en 
outre I'etape de copie desdites informations de con- 
trole de charge d'un autre champ predetermine vers 
ledit champ predetermine. 

5. Procede selon la revendication 2, dans lequel ledit 
en-tete d'adresse est un URI (100) d'un en-tete de 
route SIP. 

6. Procede selon la revendication 2 ou 5, comprenant 
en outre I'etape consistant a prevoir une pluralite de 
sous-champs (121 a 12n) dans ladite partie utilisa- 
teur (1 20) afin d'acheminer differents types desdites 
informations de controle de charge. 

7. Procede selon la revendication 6, dans lequel ladite 
partie utilisateur (120) est distribute et divisee en 
lesdits sous-champs (121 a 12n). 

8. Procede selon la revendication 6, dans lequel au 
moins I'un d'une structure, d'un ordre et d'une utili- 
sation desdits sous-champs (121 a 1 2n) est prede- 
termine. 

9. Procede selon I'une quelconque des revendications 
6 a 8, dans lequel lesdits sous-champs (121 a 12n) 
sont separes par une chaTne de bits, un caractere 
ou une chaTne de caracteres predetermines. 

10. Procede selon la revendication 1, dans lequel une 
adresse virtuelle est partagee par une pluralite de 
noeuds de processeur. 

11. Procede selon la revendication 10, dans lequel ledit 
noeud de processeur possede une fonctionnalite de 
controle d'appels d'un reseau cellulaire base sur un 
IP. 

12. Procede selon I'une quelconque des revendications 
2 a 1 1 , dans lequel lesdites informations de contr6le 
de charge comprennent un numero de port indiquant 
un premier port de reception d'un message de re- 
queue. 

13. Procede selon I'une quelconque des revendications 
2 a 1 2, dans lequel lesdites informations de controle 
de charge comprennent un second numero de port 
indiquant un second port de reception d'un message 
de reponse. 



a) placer des informations de controle de charge 
dans un champ predetermine (121 a 12n) d'un 
message ; 

b) acheminer ledit message sur ledit reseau de 
donnees par paquets ; 

c) verifier lesdites informations de controle de 
charge sur le trajet d'acheminement dudit 
message ; et 

d) selectionner une ressource de traitement du- 
dit reseau de donnees par paquets en reponse 
au resultat de ladite etape de verification. 
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14. Procede selon la revendication 1 , dans lequel lesdi- 
tes informations de control© de charge comprennent 
une premiere information indiquant si une session 
dudit message existe deja ou non. 

5 

15. Procede selon la revendication 14, dans lequel les- 
dites informations de controle de charge compren- 
nent une seconde information indiquant une identi- 
fication de ladite session existante. 

10 

1 6. Procede selon la revendication 1 4 ou 1 5, dans lequel 
lesdites informations de contr6le de charge sont 
stockees dans un champ d'en-tete de route, un 
champ d'en-tete de liaison, ou un champ d'en-tete 

de contact d'un message SIP. 15 

17. Procede selon I'une quelconque des revendications 
1 4 a 1 6, dans lequel lesdites informations de controle 
de charge sont des informations masquees non si- 
gnificatives pour les autres reseaux. 20 

18. Procede selon I'une quelconque des revendications 
1 4 a 1 7, dans lequel lesdites informations de controle 
de charge sont definies comme etant une partie d'un 
nom d'hote d'un champ d'en-tete. 25 

19. Procede selon I'une quelconque des revendications 
1 4 a 1 7, dans lequel lesdites informations de controle 
de charge sont definies comme etant un parametre 
d'un champ d'en-tete. 30 

20. Procede selon I'une quelconque des revendications 
1 4 a 1 7, dans lequel lesdites informations de controle 
de charge sont definies comme etant un numero de 
port d'un champ d'en-tete. 35 

21 . Procede selon la revendication 20, dans lequel ledit 
numero de port est utilise pour differencier un pre- 
mier message de messages suivants. 

40 

22. Procede selon I'une quelconque des revendications 
1 4 a 1 7, dans lequel lesdites informations de controle 
de charge sont definies comme etant un champ d'en- 
tete d'extension d'un champ d'en-tete. 

45 

23. Procede selon I'une quelconque des revendications 
1 4 a 1 7, dans lequel lesdites informations de controle 
de charge sont placees dans une partie de charge 
payante dudit message. 

50 

24. Procede selon la revendication 15, comprenant en 
outre les etapes d'extraction de ladite seconde in- 
formation en reponse a une detection de ladite pre- 
miere information, et d'utilisation de ladite seconde 
information pour ladite etape de selection. 55 

25. Procede de distribution d'informations de controle 
de charge sur un reseau a commutation de paquets, 



comprenant les etapes consistant a : 

a) creer une premiere information de controle 
de charge destinee a selectionner des ressour- 
ces de traitement dudit reseau par paquets dans 
un premier element de reseau (20) ; 

b) placer ladite premiere information de controle 
de charge dans un champ predetermine d'un 
message ; 

c) acheminer ledit message vers un second ele- 
ment de reseau (40) ; 

d) stacker ladite premiere information de con- 
trole de charge dans ledit second element de 
reseau ; 

e) creer une seconde information de controle de 
charge destinee a selectionner des ressources 
de traitement dudit reseau par paquets dans le- 
dit second element de reseau ; 

f) placer ladite seconde information de controle 
de charge dans un champ predetermine d'un 
second message ; 

g) acheminer ledit second message vers ledit 
premier element de reseau ; et 

h) stocker ladite seconde information de contr8- 
le de charge au niveau dudit premier element 
de reseau. 

26. Dispositif de reseau destine a controler une charge 
de traitement sur un reseau de donnees par paquets, 
ledit dispositif (20, 40) comprenant : 

a) un moyen de verification destine a verifier une 
information de controle de charge fournie dans 
un champ predetermine (121 a 12n) d'un 
message ; 

b) un moyen de selection destine a selectionner 
une ressource de traitement pour ledit message 
en reponse audit moyen de verification. 

27. Dispositif de reseau selon la revendication 26, dans 
lequel ledit dispositif de reseau (20, 40) comprend 
une fonctionnalite de controle d'etat d'appels d'un 
reseau cellulaire base sur un IP. 

28. Dispositif de reseau selon la revendication 26 ou 27, 
dans lequel ledit moyen de selection est agence afin 
de selectionner un noeud de processeur predeter- 
mine auquel ledit message est distribue. 

29. Dispositif de reseau selon la revendication 26 ou 27, 
dans lequel ledit moyen de selection est agence afin 
de declencher la creation d'une nouvelle session. 

30. Dispositif de reseau selon la revendication 29, dans 
lequel lesdites informations de controle de charge 
comprennent une premiere information indiquant si 
une session dudit message existe deja ou non. 
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31 . Dispositif de reseau selon la revendication 30, dans 
lequel lesdites informations de controle de charge 
comprennent une seconde information destinee a 
identifier ladite session existante. 

32. Dispositif de transmission d'un message a un reseau 
de donnees par paquets, ledit dispositif (10, 20, 40) 
etant agence afin de placer dans un champ prede- 
termine(121 a 12n)dudit message des informations 
de controle de charge permettant de selectionner 
des ressources de traitement dudit reseau de don- 
nees par paquets. 

33. Dispositif selon la revendication 32, dans lequel ledit 
dispositif comprend une fonctionnalite de controle 
d'etat d'appels d'un reseau cellulaire base sur un IP. 

34. Dispositif selon la revendication 33, dans lequel la- 
dite fonctionnalite de controle d'etat d'appels est une 
fonctionnalite de controle d'etat d'appels de desserte 
ou une fonctionnalite de controle d'etat d'appels de 
proxy. 

35. Dispositif selon I'une quelconque des revendications 
32 a 34, dans lequel ledit dispositif est agence afin 
de placer lesdites informations de controle de charge 
dans une partie utilisateur (120) d'une adresse d'en- 
tete (100) dudit message. 

36. Dispositif selon la revendication 35, dans lequel la- 
dite adresse d'en-tete est un SIP URI (100). 

37. Dispositif selon I'une quelconque des revendications 
32 a 34, dans lequel ledit dispositif est agence afin 
de placer lesdites informations de controle de charge 
dans un nom d'hote, un parametre d'en-tete, un nu- 
mero de port, ou un champ d'en-tete d'extension 
d'une partie d'en-tete dudit message, ou dans une 
partie de charge payante dudit message. 

38. Dispositif selon la revendication 37, dans lequel les- 
dites informations de controle de charge compren- 
nent une premiere information indiquant si une ses- 
sion dudit message existe deja ou non. 

39. Dispositif selon la revendication 38, dans lequel les- 
dites informations de controle de charge compren- 
nent une seconde information indiquant ladite ses- 
sion existante. 

40. Systeme de controle d'une charge de traitement 
dans un reseau de donnees par paquets, ledit sys- 
teme comprenant : 



de donnees par paquets ; et 

b) un second element de reseau (20, 40) destine 
a verifier lesdites informations de controle de 
charge sur le trajet d'acheminement dudit 

s message ; et a selectionner une ressource de 

traitement dudit reseau de donnees par paquets 
en reponse au resultat de la verification. 

41. Systeme de distribution d'informations de controle 
10 de charge dans un reseau a commutation de pa- 
quets, ledit systeme comprenant : 

a) un premier element de reseau (20) destine a 
creer une premiere information de controle de 
15 charge destinee a selectionner des ressources 

de traitement dudit reseau par paquets et a pla- 
cer ladite premiere information de controle de 
charge dans un champ predetermine d'un 
message ; et 

20 b) un second element de reseau (40) destine a 

recevoir ledit message, et a stacker lesdites in- 
formations de controle de charge, a creer une 
seconde information de controle de charge des- 
tinee a selectionner des ressources de traite- 

25 ment dudit reseau par paquets, a placer ladite 

seconde information de controle de charge dans 
un champ predetermine d'un second message, 
et a acheminer ladite seconde information de 
controle de charge vers ledit premier element 

30 de reseau ; 

c) dans lequel ledit premier element de reseau 
(20) est adapte afin de stacker ladite seconde 
information de controle de charge. 

35 42. Systeme selon la revendication 40 ou 41 , dans le- 
quel lesdits premier et second dispositifs de reseau 
comprennent une fonctionnalite de controle d'etat 
d'appels. 

40 



45 



a) un premier element de reseau (10, 20, 40) ss 
destine a placer des informations de controle de 
charge dans un champ predetermine (121 a 
1 2n) d'un message a acheminer sur ledit reseau 
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